Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add GetCacheKeys() method to allow for partial key removal operations #153

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

CascadeJonathan
Copy link

I've read numerous requests to have a better mechanism to enumerate through keys that are stored in cache. This makes it very convenient to expire an entire set of cached items based on a prefixing pattern. While I understand there are various other ways to achieve this (like using cancellation tokens, or multiple caches) having access to a dictionary of keys makes for a very simple implementation.

Internally this maintains a ConcurrentDictionary with all of the cache keys, and a metadata object about each cached item. When calling GetCacheKeys() you get a copy of the key dictionary at a point in time. It's fully possible that a separate process changes the dictionary after the copy is taken. If the caller needs to prevent the dictionary from being modified while consuming the key dictionary that locking could be added external of LazyCache. For many use cases that level of control wouldn't be needed.

I've also added tests to demonstrate the dictionary working properly.

Jonathan King and others added 2 commits May 7, 2021 16:54
@alastairtree
Copy link
Owner

Hi thanks for this. The challenge with accepting this is that I imagine all operations against the cache will now take around twice as long because there are effectively 2 caches to maintain. There are some benchmarks in the project that could be used to demonstrate this. In addition if an item in the cache expires due to age I don't think it will be removed from the list of keys uoi added? So potentialy the list of cache keys could grow forever? Based on the current design of your implementation I don't think it would be possible to accept a PR like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants